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PARALLEL SELECTION PROCESSING FOR FINANCIAL PROCESSING IN A 
RELATIONAL DATABASE MANAGEMENT SYSTEM 
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9522; 
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SYSTEM," filed on April 30, 2001, by George Robert Hood, attorney's docket number 
9435; 

UtiUty AppUcation Serial No. 09/845,851, entitled "SHAREHOLDER VALUE 
ADD FOR FINANCIAL PROCESSING IN A RELATIONAL DATABASE 
30 MANAGEMENT SYSTEM," filed on April 30, 2001, by George Robert Hood, attorney's 
docket number 9511; 
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DATABASE MANAGEMENT SYSTEM," filed on June 29, 2000, by George Robert 
Hood, attorney's docket number 9008; and 
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IMPLEMENTATION FOR FINANCIAL PROCESSING IN A RELATIONAL 
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Hood, attorney's docket number 9011; 
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ttArKTMOIlNT) QFTHP.TNVRNTION 

1 . Field of the Invention. 

This invention relates in general to financial processing systems performed by 
computers, and in particular, to the implementation of parallel selection processing for 
5 finanaal processing using data accessed from a relational database management system. 

2. Description of Related Art. 

Financial processing systems provide tools for financial analysis of accounting data. 
Typically, each financial processing system operates in a unique way and approaches financial 
10 analysis differendy. Some financial processing systems are advanced in their approach to 
profitability calculations, and others are still at a more basic level. In addition, there is no 
agreement as to the rules for profitability calculations, outside of generally accepted 
accounting policies that external auditors use. 

Yet, the majority of financial processing systems are inefficient in their accessing of 
lational databases. There is a need, then, for an improved approach to selecting account 
and event data from a relational database, especially in the area of parallel processing. 
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SUMMARY OF THE INVENTION 
A Value Analyzer system is a data-driven computer-facilitated financial model that 
provides accurate and consistent profitability calculations using account and event data 
stored in a relational database managed by a relational database management system 
(RDBMS), wherein the account data comprises attributes of the accounts being measured 
and the event data comprises attributes of account-related transactions. A selector function 
uses selection criteria to select accounts and events from the relational database in order to 
25 generate a number of inputs for profitability calculations. 

BRIEF QESCRIPTIQN np THF DRAWINGS 
Referring now to the drawings in which like reference numbers represent 

corresponding parts throughout: 
30 FIG. 1 illustrates an exemplary hardware and software environment according to the 

preferred embodiment of the present invention; 
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FIG. 2 is a data flow diagram that illustrates the operation of the Value Analyzer 
according to the preferred embodiment of the present invention; 

FIG. 3 illustrates a selector function included in a Value Analyzer system according 
to the preferred embodiment of the present invention; and 

FIG. 4 is a flow chart illustrating the logic of the preferred embodiment of the 

present invention. 

DgTAl ED DESCRJEriQ^ OF THEJBEEEBBEaEMBQDlMEMI 

In the following description of the preferred embodiment, reference is made to the 
accompanying drawings which form a part hereof, and in which is shown by way of 
nlustration a specific embodiment in which the invention may be practiced. It is to be 
understood that other embodiments may be utilized and structural changes may be made 
without departing from the scope of the present invention. 

OVERVIEW 

A Value Analyzer system is a data-driven computer-facilitated financial model that 
provides accurate and consistent profitability calculations using account and event data 
stored in a relational database managed by a relational database management system 
(RDBMS) wherein the account data comprises attributes of the accounts being measured 
and the event data comprises attributes of account-related transaction, A selector function 
uses selection criteria to select accounts and events from the relational database in order to 
generate a number of inputs for profitability calculations. 

HAKOWARF aktp SOFTW^RF FNVT R ONMENT 
FIG 1 illustrates an exemplary hardware and software environment according to the 
preferred embodiment of the present invention. In the exemplary environment, a computer 
system 100 implements a financial processuig system, known as the Value Analyzer system, 
in a three-tier client-server architecture, wherein the first or client tier provides a Value 
Analyzer Ghent 102 that may include, inter alia, a graphical user interface (GUI), the second 
) or middle tier provides a Value Analyzer Calculation Engine 104 for performing functions as 
described later in this application, and the third or server tier comprises a Relational 
DataBase Management System (RDBMS) 106 that stores data and metadata in a relational 

A 
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database. The first, second, and third tiers may be implemented in separate machines, or 
may be implemented as separate or related processes in a single machine. 

In the preferred embodiment, the RDBMS 106 includes at least one Parsing Engine 
(PE) 108 and one or more Access Module Processors (AMPs) 110A-110E storing the 
5 relational database in one or more data storage devices 112A-112E. The Parsing Enguie 108 
and Access Module Processors 110 may be implemented in separate machines, or may be 
unplemented as separate or related processes in a smgle machine. The RDBMS 106 used in 
the preferred embodiment comprises the Teradata® RDBMS sold by NCR Corporation, the 
assignee of the present invention, although other DBMS's could be used. 
10 Generally, the Value Analyzer Client 102 includes a graphical user interface (GUI) 

for operators of the system 100, wherein requests are transmitted to the Value Analyzer 
Calculation Engine 104 and/or the RDBMS 106, and responses are received therefrom. In 
response to the requests, the Value Analyzer Calculation Engine 104 performs the functions 
described below, including formulating queries for the RDBMS 106 and processing data 
15 retrieved from the RDBMS 106. Moreover, the results from the functions performed by the 
Value Analyzer Calculation Engine 104 may be provided direcdy to the Value Analyzer 
Client 102 or may be provided to the RDBMS 106 for storing into the relational database. 
Once stored in the relational database, the results from the functions performed by the 
Value Analyzer Calculation Engine 104 may be independendy retrieved from the RDBMS 
20 1 06 by the Value Analyzer Client 1 02. 

Note that the Value Analyzer Client 102, the Value Analyzer Calculation Engine 104, 
and the RDBMS 106 may be implemented in separate machines, or may be implemented as 
separate or related processes in a single machine. Moreover, in the preferred embodiment, 
the system 100 may use any number of different parallelism mechanisms to take advantage 
of the parallelism offered by the multiple tier architecture, the client-server structure of the 
Value Analyzer Client 102, Value Analyzer Calculation Engine 104, and RDBMS 106, and 
the multiple Access Module Processors 110 of the RDBMS 106. Further, data within the 
relational database may be partitioned across multiple data storage devices 112 to provide 
additional parallelism. 

30 Generally, the Value Analyzer Client 102, Value Analyzer Calculation Engine 104, 

RDBMS 106, Parsing Engine 108, and/or Access Module Processors 110A-110E comprise 
logic and/or data tangibly embodied in and/or accessible from a device, media, carrier, or 
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signal, such as RAM, ROM, one or more of the data storage devices 112A-112E, and/or a 
remote system or device communicating with the computer system 100 via one or more data 

communications devices. 

However, those skilled in the art will recognize that the exemplary environment 
5 illustrated in FIG. 1 is not intended to limit the present invention. Indeed, those skilled in 
the art will recognize that other alternative environments may be used without departing 
from the scope of the present invention. In addition, it should be understood that the 
present invention may also apply to components other than those disclosed herein. 

1Q VAT. UK ANAJ -V7.F.R OPERATION 

The Value Analyzer system is a data-driven computer-facilitated financial model that 
provides accurate and consistent profitability calculations using account, event and 
organization data stored in the RDBMS 106, wherein: (1) the account attributes comprise 
data about accounts being measured, (2) the event attributes comprise data about account- 
15 related transactions, and (3) the organization attributes comprise data about the 

organization's financial status. The profitability calculations performed by the Value 
Analyzer system rely on a Five Factor Atomic Profit Metric (FFAPM): 
Profit = Net Interest Revenue (NIR) . 
+ Other Revenue (OR) 
20 - Direct Expense (DE) 

Indirect Expense (IE) 
Risk Provision (RP) 
NIR + OR - DE - IE - RP 
In the above equation, it is assumed that the sign of elements that reduce profit are 
25 negative and those that contribute are positive. 

Each of the five factors of FFAPM are defined below: 

• Net Interest Revenue. This component comprises interest revenue, and is 
the largest component of profitability (e.g., from loans, deposits, cash, etc.). 

• Other Revenue. This component comprises non-interest revenue (e.g., fees 
30 and commissions), including those driven by events (e.g., open account, 

excessive counter withdrawals, early payout penalties, etc.). 
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mpn< , p( ; driven bv events that 
. Dtfect Expense. This component composes expenses dnven y 

are attributable to accounts. 
. .na.ec. Expense. This component ^ «P— *« » ~ 

r tof ao mgb »s m « d ,ac M e„o t a n ,e nby accoun— act^.such 
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MM and acrmu costs (e.g., the CEO's salary, etc). 
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credt, common, operations, regulatory nsks, pohuca, nsks, etc. 
Ea ch of these Eve factors can be measured fot a desned penod (dany, weeHy, 

t tc , Moreover each factot , essendaHy dtsctete and independent wtu, 
monthly, quarterly, etc.). Moreove , ^ ^ ^ 

^amenraUy orfferen. character^, whrch srreng* ^ ^ ^ 

out pn. to determine relationships between acconnt, event g 
consistent multiple dimensional aggregation. 

The FFAPM is -atomic" in that profirabuity ts computed nsmg 

RDBMS 106. There are three aspecrs to this: 

. eomponenrsofproh-rymayhemeasmeahe.o.meacconn.U^ 

JL which make up account activity over an accounnng penod) 
accumulated to the account, 
. components of prontabthty may be measured drrectiy , me account .eve, 
( S uch as mterest paid or earned for an accounting penod), 

. components of profitabihty may be known, obtamed. or aggregated a. , 

^IrleveUndmaybeappomoneddownrospecificaccounrsandevenrs 

according to various rules. 
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y>t,na AMAI.Y7.F. B "ATA FLOW 
FIG 2 is a data flow d,agnnr mat illustrates Ac operaoon of dae Value Analyze, 
system according to the preferred embodiment of rhe preaent tendon. Wfihin me Value 
Analyze, Calculadon Enguae 104, one o, Profitabary Calculous 200 accept a 
number of inputs tncluding Account Attributes 202, Even, Attributes 204, Organizaoon 
Atmbu.es 206, and Ptofi, Factors 208. Thereafter, the Profitability Calculations 200 nrvoke 
one o, more ft*. 210 mat gene,a,e me FFAPM 212, which in mm are used to ceate me 
Database 212. The Database 212 may be ,ep,esen,ed along account, even,, o, organtzauon 
dimenstons, o, along other dimensions as may be .conned. These dements are descnbed » 
more detail below. 
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Tnpnt Definitions 

Account Attributes 202 compns. data about the accounts bemg measured. Tins dan, 
includes: balance, tate (o, interest accrued), product identification, hunts, expected default 
frequency, and various dates (e.g, open, rate rese,, Us, payment, neat payment matunty, 
etc.). 

Event Attributes 204 comprise data about account-related events or transactions. 
Th, data includes: account identification, event or transaction amounts, event or transaction 
location, event or transaction time, counter-party notification, event or transacuon type 
(e g. loan payment, interest paid, loan draw down amount, etc.). 

Organization Attributes 206 comprise data about the financial status of the 
organization. This data includes: balance sheet and profit statement amounts aggregated by 
the legal or management entities that own the account base bemg measured. 

Profit Factors 208 include parameter values necessary to perform the Profitability 
Calculations 200. The major classifications of this data include: 

. Funds transfer rates are pricing methods that require matched maturity 

opportunity rates for use in valuing each account's marginal use or source of 
internal funds. 

. Unit costs are used for Direct Expense calculations, where a total cost is 

provided as an Organization Attribute 206 and the Unit Cost is then derived 
by dividing total cost by actual volume. Unit Costs can be either standard, 
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c 

actual, or market, and ideally represent marginal values (if "fully absorbed 
measures" are used, then the usefulness of allocated amounts is diminished.) 
Allocated amounts are used in both Other Revenue and Indirect Expense 
calculations, wherein the allocated amounts are apportioned amongst all 
accounts in a group. 

Miscellaneous calculation values may comprise, for example, the number of 
days in a profit measurement period, an equity allocation weighting, etc. 
These values are known as "modeling" parameters. 
Amortization parameters are used in interest amortization, which requires 
interest rates and life values used by straight-line amortization and by 
declining balance of amortization. 

Risk measurement parameters are used in Risk Provision calculations, which 
require various factors, such as: loss rates, reserve percentages, exposure 
factors, recovery rates, default probabilities and collection costs. 
Tax rates are required for after-tax profit calculation. The Value Analyzer is 
designed to calculate pre-tax income on a taxable equivalent basis (where an 
effective tax rate is all that is required to transform pre-tax income into after 
tax earnings, i.e., Profit). 



Rules 

The Profitability Calculations 200 use one or more Rules 210 applied to data 
retrieved from the RDBMS 106. These Rules 210 include, inter alia, the following: 

jreattnents. Every account with cash flows affecting a organization's balance sheet 
requires a method of valuing the account's use of internal funds. One approach is "matched 
maturity funds transfer pricing," which uses a canonical representation of an account's 
funding characteristics and then determines a value based on adjusted market yields for each 
instance that requires an interest rate transfer price to calculate an account's marginal Net 
Interest Revenue. 

Equity Allocation. In order to provide precise Net Interest Revenue calculations, the 
amount of equity funds required at an account must be determined. This rule allows for 
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nfit for expected future losses is known as 

m its account levei iu accounts. 

BMbkBa^tiaW Trofit Bsation . The Value 

Aoaly*. *m adjusts «- „ e ^ ^ as taxable ^ 

for any number of periods, the adjustment q£ interest-related Profit, the Value Analyzer 
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The following < 
. Retrieve data from the RDBMS 106. 
2 Calcu^reNermrerearRevenueforeve^eoont. 

- account. 
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3 Calculate Other Revenue for every : 

4 . CalculateDirectExpenseforeveryaccount. 

5 CalculatelndnectExpenseforeveryaccount. 

6 . CalcukteRiskProvisionforeveryaccount. 

7 Calculate Profit for every account ppAPM into the RDBMS 

, StoretheFFAPMProfitandthefivefactorsofFFAPM 

106 " , ^^^^^^^ 

30 FFAPM as necessary. accoon ,-level ealcoboona. Steps 2, 5, *, 5. »» d 

Note rhat steps 2 through 6 perform a ^ ^ h 

.e.oheperforureduadepeudeofiyand.parafiel.whues.ep 
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completed. 

QutgujJ2«£siti°S , more values for the five factors of 

ta FFAPM 2,0, and spectficall,, the NO. «. ' ta ^ 

relational database. 

fig. 

relational database managed by the KU , A ~ buBS 202 and Event Attributes 

Ae Pre.fnabd.tv Calculauons 200, nadudtng Account At»bu« ^ ^ 

- »~ ^ T 0 ln g b the Selectot fcncdon 300 could b. used 
capabilities of the Selector fnncnon 300, althoug 

with these inputs as well. 

S -^^ Sm , SekctoI function 300 uses one or more sets of 

I nt heValueAnalyzer S ystem,theSelector rocessed . Inthe 

r- ■ W to determine which accounts and events should p 
Selection Cntena 302 to determrn be ^ 

pre ferred embodiment, the followmg types of Selecuon 
Product Groups; 

Balance Types; 
Account Event Groups; 
Master Account Event Groups; 

Account Attributes; and 
Master Account Attributes. 
Other types of Selection Crrteria 302 may be used as well. 
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The Selecdon CAcda 302 may compose annbu.es, P^tes, operators and/or 
fcncdons, wherern a group of accouna . even. that satisfy .he Select Ota- 30 
compose pardons. For example, it is poasibk to compare an account atmbute (. e. a 

Kf Je to a Utera, va.oe that is reso.ved by a .ookup function). Op— -T «W. aoy 

. , . • ->-<=<> BETWEEN, etc., and 
number of different relational operators, i.e, -, > , , . 

functions may comprise aggregate or other functions. 

The Selection Criteria 302 may also mclude dynamic event attributes. For example, 
mu lti P le event attributes may be defined for each account. The event attribute definition can 

entity of the event attributes. This means that the selection of accounts having specific 
combinations of event attributes is dynamic, rather than static. 

g»„t™. Target nnrl TW" Components 

„ tire Valoe Analyze, system, each oale performed by the Profitably Cannon 
200 can indude muldpie sets of Selecdon Catena 302. Specific, eacb ntie performed by 
4, ProntabOtiy Caption 200 is composed of Source, Taage. and Dover component and 
ccboftbese components can baveSc.ecdonCd.eda 302. In dus con.e«, a Souace 
component is a source of funds .o be aUoca.ed, a Target componen. is a .age. of funds . 
be located, and a Dover componen. is an a«bu.e - function ma. con.ro, me aUocau 

of fcnds faom me sou.ee .o me .aage. (eg., accoun. atuabu.es, number of accounts, even. 

attributes, even. coun.s, even, amounts, erc). The Sdection Cntena 302 for dn.se 

components can be dynamically specified by die user. 

25 Amounts and Counts 

A„ .mount can be spaded by me user for dre Source componen., and bodr 
counts and counts can be specified for Dover components. Tire specification of amounts 
, conn., combmed wdh dre Selecdon Criteria 302, reuuties dra, dre Se.ec.or funcuon 
dy nanuca% sdec. me proper sets of accoun. or even*, and aggregate dr. user-specdaed 

M Luntsoacount, Generany, dus sdecdon and aggrcgadon wti. be drfferen. fiom one ntie 
CO another, and fiom one Profitability Calculation 200 to another. 
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Event Thresholding 

The Selector function 300 may use the amounts and counts to perform event 
thresholding when forming an Event Group. For example, the Selector function 300 may 
be programmed to only select accounts that have some specified number of some specified 
combinations of event attributes. Specifically, using the example, the Selector function 300 
looks for accounts that meet any of the Selection Criteria 302 specified above, wherein the 
amount or count of the events is summed to determine whether they meet a user-specified 
thresholding requirement. 

Rule Screening 

Once the lists of Selection Criteria 302 have been specified, the next step is to screen 
the Profitability Calculation 200 rules and Selection Criteria 302. Specifically, any rules or 
criteria that the Selector function 300 does not need to execute can be removed. For 
example: 

1 . If a Profitability Calculation 200 rule is an apportionment rule, and the 
apportionment amount is $0. 

2. If a Profitability Calculation 200 rule does not have any Selection Criteria 
302, then the Selector function 300 can skip the rule. This occurs, for example, when a rule 
is applied to all accounts, i.e., when no Selection Criteria 302 are applied. Note that the rule 
can be removed only if the Source, Driver, and Target components all lack Selection Criteria 
302. 

3. If the Selection Criteria 302 are objectively invalid, then the Profitability 
Calculation 200 rule can be removed. For example, if an account attribute has two equality 
comparisons to different values, e.g., "Select all accounts where account = "checking 
account," balance = $5000, and balance = $12000, which is objectively invalid, the 
profitability rule can be removed (with an error message displayed). 

Operation 

Using the Selection Criteria 302 for each of the components, the Selector function 
300 dynamically generates SQL statements to select the proper accounts and events from an 
account table and event log table in the relational database. The account table contains all of 
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the accounts at a financial institution, and the event log table contains all of the account 
events or transactions that occurred during a specified period at the financial institution 

The Selector function 300 can perform parallel processing of the Selection Criteria 
302, which allows the Selector function 300 to optimize the selection of accounts and events. 
Using this process, similar Selection Criteria 302 are grouped together and processed 
independently and in parallel by the RDBMS 106, and the results therefrom are stored in 

temporary work tables. 

The Selector function 300 uses one or more parameterized templates to dynamically 
generate the SQL statements. This parameterized template typically comprises a join of 
(potentially) multiple tables within the relational database to a constraint table (storing the 
Selection Criteria 302) and an in-list table (storing IN clauses for the SQL templates). Both 
the constraint and in-list tables are created and populated from the Selection Criteria 302. 

Specifically, there are several very important steps in generating the SQL statements: 

1 . Substantially similar Selection Criteria 302 are grouped in order to combine 
them into one account-partitioning set of SQL statements. In this context, "similar" does 
not necessarily mean identical, e.g., certain Selection Criteria 302 are considered identical for 
the grouping function and are later altered to match the original SQL statements. 

2. Once the Selection Criteria 302 are grouped, it is necessary to convert and/or 
combine some of the Selection Criteria 302 in order to ensure that every Selection Criteria 
302 can be expressed in the fewest number of templates. 

3. One or more constraint tables are created and populated for each group of 

Selection Criteria 302. 

4. One or more in-list tables are created and populated for all groups of 

Selection Criteria 302. 



Standardizing Se ction Criteria 

For the purpose of grouping Selection Criteria 302, the Selector function 300 treats 
the relational operators, e.g., =, <, >, =>, <=, as equivalent to a BETWEEN operation. In 
fact, the Selector function 300 converts these relational operators into an equivalent 
BETWEEN operation according to the mappings in the following table: 
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Operator 


Maps to 


TVFTWFFN 

DDI WCil-ji" 


Left Value 


AND 


Right Value 


= X 


Maps to 


BETWEEN 


X 


AND 


X 


<X 


Maps to 


BETWEEN 


MIN(X) 


AND 


LOWER(X) 


<=X 


Maps to 


BETWEEN 


MIN(X) 


AND 


X 


>X 


Maps to 


BETWEEN 


HIGHER(X) 


AND 


MAX(X) 


>= X 


Maps to 


BETWEEN 


X 


AND 


MAX(X) 



wherein: 

• MAX(X) is the maximum value of X in the domain of its data type. For 
example, if X is a BYTEINT value, then the maximum value of X is 127. 

• MIN(X) is the minimum value ofX in the domain of its data type. For 
example, if X is a BYTEINT value, then the minimum value of X is -128. 

• LOWER(X) is the next lowest value of X in the domain of its data type. For 
example, if X is a BYTEINT value, then the next lower value of X is <X - 1' (unless X is 
already -128). 

• HIGHER(X) is the next greater value of X in the domain of its data type. 
For example, if X is a BYTEINT value, then the next greater value of X is <X + 1' (unless X 
is already 127). 

If the relational operator in the Selection Criteria 302 is of the type '>=', '<- , '>', or 
'<', then there may exist another Selection Criteria 302 within the group of Selection Criteria 
302 that matches, i.e., that would form a valid BETWEEN operation. To match first and 
second Selection Criteria 302, the first and second Selection Criteria 302 must be the same 
attribute, and if the relational operator of the first Selection Criteria 302 is either '>=' or '>', 
then it will match either '<=' or '<' in the second Selection Criteria 302. Likewise, if the 
relational operator of the first Selection Criteria 302 is «<=' or <<\ then it will match either 
<>=' or '>' in the second Selection Criteria 302. 

Once a matching pair of first and second Selection Criteria 302 is found, the 
combination into one BETWEEN operation is straightforward. It is worth noting that, just 
as in the simple case, '< X' results in T3ETWEEN Y AND LOWER(X)' and <>X' results in 
'BETWEEN HIGHER(X) andY'. 
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Grouping Selection Criteria 

The Selector function 300 optimizes the dynamic generation of SQL statements, so 
that multiple Selection Criteria 302 can be processed in parallel by the RDBMS 106. 
Generally, this requires an understanding of the operation of the Parsing Engine 108 of the 
RDBMS 106, and how it transforms SQL statements into an operator tree that, in turn, can 
be used to generating multiple, parallelized access plans for execution by Access Module 
Processors 110A-E of the RDBMS 106. 

In generating the SQL statements, the Selector function 300 groups multiple sets of 
Selection Criteria 302 together and processes the groups in parallel to the extent possible, 
and generates several sets of output tables. The goal is to process similar selection predicates 
together at the same time, so that fewer passes need to be made through the tables in the 
relational database. In a final pass, these output tables are filtered and combined to produce 
the correct sets for each source, target, and driver in the Profitability Calculation 200 rules. 

This step is necessary because the Profitability Calculations 200 are scripts that 
operate against known, statically defined, tables. In the Value Analyzer system, the 
specification of Selection Criteria 302, and the attributes that can be used in the selection 
process, are completely dynamic and user-driven. There is no way for the scripts to contain 
this knowledge, nor can it be predefined as part of the scripts. The dynamic nature of the 
profitability rules using the Selector function is a core feature of the Value Analyzer system, 
and is one of the key competitive advantages that differentiates the Value Analyzer system 
from other profitability solutions. 

When grouping Selection Criteria 302, the following is required: 

1. The Selection Criteria 302 has to be applied to the same level of accounts. 

2. That each of the Selection Criteria 302 are of the same types of Selection 
Criteria 302. For example, if two Selection Criteria 302 include both Product Group and 
Account Attribute, these can be grouped together. If one of the Selection Criteria 302 
includes only Product Group, and the other Selection Criteria 302 includes both Product 
Group and Account Attribute, then these cannot be grouped together. 

3. That each of the Selection Criteria 302 access the same attributes or columns. 
Note that an alternative embodiment would only require that each of the Selection Criteria 
302 access the same table. 
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Using the above, each distinct group of Selection Criteria 302 can be processed 
independendy. This allows the Selector function 300 to process each distinct group of 
Selection Criteria 302 in parallel. In this context, a partition is a set of one or more accounts 
that satisfy one or more Selection Criteria 302, in order to apply costs and revenues to each 
account. 



Output Tables 

After the temporary work tables have been created, the Selector function 300 filters 
and combines the temporary work tables, yielding output tables corresponding to the inputs 
for the Profitability Calculations 200, namely, the Account Attributes 202 and Event 
Attributes 204. These output tables include the account partitions for the rule, wherein the 
account partitions represent the target accounts against which the profitability rules are 
applied. The output tables are then processed by one or more of the Profitability 
Calculations 200 in the Value Analyzer Calculation Engine 104 to accomplish a final result. 

T OOTC OF THE PREFERRED FMBODIMENT 
FIG. 4 is a flow chart illustrating the logic of the preferred embodiment of the 
present invention. Those skilled in the art will recognize that this logic is provided for 
illustrative purposes only and that different logic may be used to accomplish the same 
results. 

Block 400 represents the Value Analyzer Client 102 accepting one or more Selection 
Criteria 302 from the user, which may include Selection Criteria 302 for Source, Target and 
Driver Components, Amounts and Counts, as well as event thresholding values. 

Block 402 represents the Value Analyzer Calculation Engine 104 invoking a Selector 
function 300 for selecting accounts and events from the relational database based on the 
specified Selection Criteria 302 prior to the execution of the Profitability Calculations 200. 

Block 404 represents the Selector function 300 performing rule screening for the 
selected accounts and events from the relational database based on the specified Selection 
Criteria 302. 

Block 406 represents the Selector function 300 standardizing the Selection Criteria 

302. 
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Block 408 represents the Selector function 302 grouping the standardized Selection 
Criteria 302. 

Block 410 represents the Selector function 300 dynamically generating SQL 
statements for the selected accounts and events from the relational database based on the 
5 specified Selection Criteria 302. 

Block 412 represents the Selector function 300 invoking the dynamically generated 
SQL statements, wherein the SQL statements are transmitted to the RDBMS 106. These 
SQL statements access account and event attributes from the database managed by the 
RDBMS 106. 

10 Block 414 represents the Parsing Engine 108 of the RDBMS 106 receiving the SQL 

statements and transforming the statements into an operator tree. 

Block 416 represents the Parsing Engine 108 of the RDBMS 106 generating one or 
more access plans from the operator tree. 

Block 418 represents the Parsing Engine 108 of the RDBMS 106 parallelizing the 
3 15 access plans, and then transmitting the access plans to their assigned Access Module 
P Processors 1 10A-E of the RDBMS 106. 

>h| Block 420 represents the Access Module Processors 1 10A-E of the RDBMS 106 

y 

ip executing the access plans, and thereby performing the required data manipulation associated 

;? s with the access plans received from the Parsing Engine 108, wherein the required data 

20 manipulation associated with the access plans are performed in parallel by the Access 
Module Processors 110A-E. 

Block 422 represents the Parsing Engine 108 of the RDBMS 106 standardizing the 
results received from the Access Module Processors 110A-E and providing the standardized 
results to the Value Analyzer Calculation Engine 104 as account and event attributes. 
25 Block 424 represents the Value Analyzer Calculation Engine 1 04 invoking and 

performing the Profitability Calculations 200 using the account and event attributes accessed 
from the RDBMS 106, as well as one or more organization attributes, profit factors and 
rules. 

Block 426 represents the Value Analyzer Calculation Engine 104 delivering the 
30 output or results from the Profitability Calculations 200 to the Value Analyzer Client 102 
and/or the RDBMS 106. With regard to the Value Analyzer Client 102, the results may be 
presented to the user, printed, or used by various other computer programs, as desired. 
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With regard to the RDBMS 106, the results may be stored for later use by the Value 
Analyzer Client 102, the Value Analyzer Calculation Engine 104, or other computer 
programs, as desired. 

CONCLUSION 

This concludes the description of the preferred embodiment of the invention. The 
following paragraphs describe some alternative embodiments for accomplishing the same 
invention. 

In one alternative embodiment, any type of computer or configuration of computers 
could be used to implement the present invention. In addition, any database management 
system, decision support system, on-line analytic processing system, or other computer 
program that performs similar functions could be used with the present invention. 

In summary, the present invention discloses a Value Analyzer system, which is a 
data-driven computer-facilitated financial model that provides accurate and consistent 
profitability calculations using account and event data stored in a relational database 
managed by a relational database management system (RDBMS), wherein the account data 
comprises attributes of the accounts being measured and the event data comprises attributes 
of account-related transactions. A selector function uses selection criteria to select accounts 
and events from the relational database in order to generate a number of inputs for 
profitability calculations. 

The foregoing description of the preferred embodiment of the invention has been 
presented for the purposes of illustration and description. It is not intended to be exhaustive 
or to limit the invention to the precise form disclosed. Many modifications and variations 
are possible in light of the above teaching. It is intended that the scope of the invention be 
limited not by this detailed description, but rather by the claims appended hereto. 
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